Note that Callable has a call() function. So if you want to pass functions around you need to call them like this: var x = my_func; x.call(). Using x() won't work.

I understood correctly:

func my_func():
    print("Hello!")

func _ready():
    my_func() # It works.
    my_func.call() # It works.
    
    var x = my_func
    x.call() # It works.
    x() # This does not work.

?

@onready

Given the frequency at which onready is used I wonder if it's not better to leave it as a keyword?

Now we have StringName in Variant so a notation for it was added: &"This is StringName"

This is a huge thing. To the point it is the default for every string in C#, Java, Lua, Javascript and... maybe Python? It may have a use far more than we think, and then requiring to use & a lot.
Basically, everything that is not straight up text. Config properties, dictionary entries, shader parameters... which brings the question of making existing dictionary-based APIs use more StringName, like raycast results for example. So to me, it almost sounds like it's text strings that should have a special syntax instead, but it might sound extreme compared to our current GDScript.

About dictionaries, they can be used a lot in GDScript because apart from classes, that's the only other way to represent named associative data. Considering we can declare them this way:

var d = {
	one = "Hello",
	two = "World"
}

print(d.one, d.two)

At the moment this still uses String all the way.
Should one and two be StringName when written in this way? Or should we always have to go through the burden of writing:

var d = {
	&"one": "Hello",
	&"two": "World"
}

print(d[&"one"], d[&"two"])

Sadly I can see why it may not be simple to do such a choice, at least with dictionaries...

Since @ is now used for annotations, writing NodePaths need the ^ prefix instead: ^"This/Is/NodePath"

I didn't know this was even a thing :O
So now we have $, ^ and & to prefix strings in order to get a node, make a NodePath, or make a StringName.

Will enums be 2nd class citizens or still 3rd?

@dalexeev yes, that is correct.

@onready

Given the frequency at which onready is used I wonder if it's not better to leave it as a keyword?

Well, I'm not sure if "frequency" is the defining point. It's more like it's tangent to execution. onready is a bit in the fence since it's delayed initialization. But also: it's just one character more.

Now we have StringName in Variant so a notation for it was added: &"This is StringName"

This is a huge thing. To the point it is the default for every string in C#, Java, Lua, Javascript and... maybe Python? It may have a use far more than we think, and then requiring to use & a lot.
Basically, everything that is not straight up text. Config properties, dictionary entries, shader parameters... which brings the question of making existing dictionary-based APIs use more StringName, like raycast results for example. So to me, it almost sounds like it's text strings that should have a special syntax instead, but it might sound extreme compared to our current GDScript.

In a way, yes, maybe making StringName by default is more useful. OTOH, many of this can be done behind the user's knowing. If you are passing as parameter to a function that accepts a StringName, it'll be converted automatically. So it's more of a question on when do you need to intern the string, which many times don't make much difference.

It might be something to consider. I probably wouldn't make multiline strings a StringName though.

About dictionaries, they can be used a lot in GDScript because apart from classes, that's the only other way to represent named associative data. Considering we can declare them this way:

var d = {
	one = "Hello",
	two = "World"
}

print(d.one, d.two)

[...]

My idea is to make that use StringName by default. This still need to be fixed in core though, because Variant::get_named() coerces to a String.

Main problem is that there's a difference between attribute and subscript (that is, doing d.one vs doing d["one"]). Well, if you do it directly it uses the same code, but if the index is a variable it just uses that value and a regular get(). There's also a difference between Lua style (one = "Hello") and Python style ("one": "Hello). The first I can make StringName the others not really. Maybe making StringName default solves this...

I have to think about it and also consult with reduz.

Since @ is now used for annotations, writing NodePaths need the ^ prefix instead: ^"This/Is/NodePath"

I didn't know this was even a thing :O

Against all odds this is actually a documented feature.

So now we have $, ^ and & to prefix strings in order to get a node, make a NodePath, or make a StringName.

Well, $ doesn't need a string, since you can do $VBoxContainer/Button just fine. But yes, we have the three prefixes.

Any way of preventing confusion between ^ and $ in particular? Warnings or errors if they're used in an inappropriate place?

Not against that syntax. but it would be great if it could also be omitted when it can be inferred, like these cases:

var name: StringName = "foo"
call("bar") # expected parameter is of type StringName

I'm a pretty new Godot user, but I thought you might want to hear from a 'common folk'. The first class signals sound awesome. However, I am confused about the need for StringName. Are there optimizations that can be had by using such a class?

Also, The removal of typed parameters seems like a regression. I've found them immensely valuable as I learn Godot and GDscript. Maybe I misunderstood and the final PR will have them back?

It seems like the readability of GDScript will decrease if we add more symbols, especially to strings as in the example from @Zylann . Maybe there are optimizations I am not aware of that would come with such changes, but I am not excited about StringName.

This is a huge thing. To the point it is the default for every string in C#, Java, Lua, Javascript and... maybe Python? It may have a use far more than we think, and then requiring to use & a lot.

var d = {
	&"one": "Hello",
	&"two": "World"
}

print(d[&"one"], d[&"two"])

Type checks
This will require quite some more time to add back. But in the bright side it should work much better than before. Including a fix to the dreaded issues with cycles.

Thats fantastic! I was often struggling with circular references, which would then create a cascade of script-errors, when i am using class_name + static typing in a lot of classes.

Are there optimizations that can be had by using such a class?

Yes, StringNames are much cheaper to compare to each other compared to regular Strings. This kind of optimization is also found in many other languages.

Also, The removal of typed parameters seems like a regression. I've found them immensely valuable as I learn Godot and GDscript. Maybe I misunderstood and the final PR will have them back?

They haven't been implemented yet, but they will be re-added before the final release.

Maybe there are optimizations I am not aware of that would come with such changes, but I am not excited about StringName.

To solve the usability issues, we could make StringName the default (or automatically infer its use when required).

This is the standard way for me to reference nodes

export (NodePath) onready var energy_label = get_node(energy_label)

Not using this will mean that any change to the tree will break paths with sometimes hard to find bugs. While using this ensures it will always work if I can run the scene.

Will this line still be possible after the update and how would it look?

(Its a bit awkward to write and I wish I could write somthing like this instead)

NodeVar energy_label

Sound really exciting!

In a way, yes, maybe making StringName by default is more useful. OTOH, many of this can be done behind the user's knowing. If you are passing as parameter to a function that accepts a StringName, it'll be converted automatically. So it's more of a question on when do you need to intern the string, which many times don't make much difference.

I think this should be transparent for the users to keep the readability and simplicity of GDScript.

@Reneator better to be patient and let the team have a clean restart, this PR is a big change, this is also the time to make or give your feedback on proposals. They are some about typing, i.e., make a fully typed workflow possible (any type, nullabe & way to force the typing) and many others.

Random suggestion, but what if instead of making normal (") string literals into StringNames and mutliline (""") string literals into Strings, we made double-quoted (" and """) string literals into Strings and single-quoted (' and ''') string literals into StringNames?

Alternatively, can we somehow use the same sigil for nodepaths and string names? (Gut feeling says "no" on this one, but maybe...)

_init is now new

#16863 (comment), #16863 (comment):

I think @Zylann's remark is pretty significant. Conceptually, new() is a static function of the class, while self is available inside _init().

yes, that is correct.

I understand that this is for performance, but this behavior is rather unusual and can be confusing. Do you plan to allow the use of x() in the future?

Now that we have Signal and Callable as Variant types, they are used to represent first-class object. So instead of calling $Button.connect("button_up", self, "on_button_up") you can get the signal and connect to the function name: $Button.button_up.connect(on_button_up). This avoids the use of strings.

What about the target parameter of connect (Where we put self)? Is it now an optional second parameter of Signal.connect()?

If so, that sounds like good behaviour to me.

$Button.button_up.connect(on_button_up), but optionally $Button.button_up.connect(on_button_up, $ListeningNode).

@nathanfranke I think path to the function already has target baked in.
$Button.button_up.connect(on_button_up) # func is here
$Button.button_up.connect(some_object.on_button_up) # func is in some_object

@katoneko Thanks, makes a lot more sense now 😄

@nathanfranke

$Button.button_up.connect($ListeningNode.on_button_up)

I think @Zylann's remark is pretty significant. Conceptually, new() is a static function of the class, while self is available inside _init().

Yeah, I remember that... and it makes me wonder how could a script/class could create a new instance of itself then, without having to rely on stunts like get_script() (not viable in static context) or circular reference to itself which would then require the inconvenience to write load(fullpath).new() or being forced to give it a global class_name. If new was a static function, you could just call new() from inside the script, both in a method or a static method, and it would just work. But if new is also the non-static constructor function, it won't. Maybe the constructor could be named _new, or just constructor(), like Squirrel?
Btw, would be nice to have destructor too.

it makes me wonder how could a script/class could create a new instance of itself

Something like this, but this makes little sense:

static func new(a: int) -> MyClass:
    var instance = MyClass.__new__()
    instance.a = a
    return instance

So, there are 3 reasonable options:

1. Leave _init as it is.
2. Rename _init to _new.
3. constructor().

I think @Zylann's remark is pretty significant. Conceptually, new() is a static function of the class, while self is available inside _init().

In practice I don't feel there's much of a difference. Having the constructor called new() and instancing as MyClass.new() makes it more clear that it's calling the new() function. You can't have a static new() in your script anyway (since MyClass.new() creates a new instance instead of calling your function) so the name was unusable. Now it has the same meaning.

Python is different because you create instances with MyClass(). So there's not a "function that you are calling". Even though in GDScript the new() function is in the GDScript class itself, having new in the script makes it more cohese.

It also simplify type checking, since MyClass.new() can be checked with the new() function in MyClass without having to rename under the hood...

Yeah, I remember that... and it makes me wonder how could a script/class could create a new instance of itself then, without having to rely on stunts like get_script() (not viable in static context) or circular reference to itself which would then require the inconvenience to write load(fullpath).new() or being forced to give it a global class_name. If new was a static function, you could just call new() from inside the script, both in a method or a static method, and it would just work. But if new is also the non-static constructor function, it won't. Maybe the constructor could be named _new, or just constructor(), like Squirrel?
Btw, would be nice to have destructor too.

AFAIK it wasn't possible before to have a naked new() to create a new instance. If it's possible, you also you apply a higher meaning to what new() is, as an implicit static method.

I believe this can be simply solved by adding a static reference to the same script, like __script__ or something. So you can do __script__.new() instead.

@Geequlim The reason GDScript is being rewritten is because of Epic megagrant money that specifically must be used for either rendering or scripting. EDIT: Sorry, this statement is misleading, as akien said below. The truth is that Godot asked for megagrant money and Epic granted it specifically for rendering or scripting, so scripting is being redone because Godot devs wanted to and the grant provided an opportunity, not just because Godot wants to spend money or do what Epic says.

https://www.patreon.com/posts/funding-and-up-36771862

As many know, we got an Epic Megagrant two months ago which basically has been used so both I (Juan) and George Marques can work full time paid by it (the Megagrant was specifically requested and granted for working on rendering and scripting, can't be used for anything else).

@yuyubibibobibo: For a language with an ecosystem, use Python bindings.

I just read the entire proposal thread on annotations and it seems to be a dope feature. I never actually encountered @"Nodepath" syntax before so I'm assuming NameString& and Nodepath^ wouldn't affect too many people. GD Script 2.0 really is an awesome upgrade.
Still, sorry I have to be the one guy that says this, but....
The change would mean that every single current plugin needs to be rewritten, more or less. This can easily trigger some people, knowing their work suddenly just got deprecated overnight. I'm quite new so I don't know if this happened with Godot 2.0 -> 3.0 transition before. I wonder if anyone who writes Godot plugins can share his or her view on the change...?

The reason GDScript is being rewritten is because of Epic megagrant money that specifically must be used for either rendering or scripting.

Please avoid making such statements. You make it sound like we have to change GDScript because we got money for it, while in reality, we asked for funding because we wanted to improve GDScript... There's a difference between doing work for the sake of using money (what your statement infers) and doing work that we planned to do, funding it with money that we requested for it.

• Why we need a new script language to replace the current one ?
  Why the new one is still the way to build from zero ?
• We have to maintain the parser，runtime，LSP，code editor，debugger etc
• We have to pay a lot of time to make it better then we might need another new one

My reasoning is similar to rewrite of the renderer, audio engine, and other code that has been redone since Godot went open source: the code is stale, full of patches, using older non-optimized techniques, hard to maintain (be adding enhancements or fixing bugs).

I took the opportunity to improve in the areas that caused confusing and had non-intuitive behavior: like yield, super calls, and setget. Those are things that I've seen multiple users having difficult understanding. Besides that, annotations were introduced to reduce the load on keywords which were added to GDScript without much thought (onready, remote and other RPC modifiers). And that's pretty much it for what changed.

First-class functions and signals is more a change in the engine API than GDScript itself.

• For user who using this language have to write everything from zero too this is really a problem

GDScript is changing and breaking compatibility, but not by that much. I will work on a translating guide and possibly an automated tool. Won't be a long guide, because there isn't a lot to say. There's no reason to "write from zero". There will be things to adapt but not that much.

In fact, I believe that GDScript changes in themselves will be less of a problem than translating the API changes from 3.x to 4.0.

Therefore, I suggest not to continue to be devoted to investing in self-developed languages. Instead, choose a scripting language with a good ecosystem, so that we can be free from the tedious tool chain development work and bug fixes. The most important thing is that game developers have also reduced the burden, they do not need to learn a new programming language that never been heard. They can use godot to develop their dream games faster with their existing programming skills.

We also lose stuff by adopting another language. The fact that we can add keywords (or now annotations) to change behavior specific to the engine is a great way to improve fast prototyping, which is one of the reasons GDScript exist. Like onready or using $ as shorthand for get_node is something hard or impossible to do with a general purpose third-party language.

It's also a fallacy that "we can be free from the tedious tool chain development work and bug fixes". Maintaining a third-party language requires updating the engine and the bindings from the third-party, making sure the new additions still work, that it didn't introduce new bugs, etc. We also need debugger integration because we need to pause the game on a breakpoints.

If you look at the C# bindings, you can see that there's a bunch of work to maintain that.

Having an integrated code editor is something that a lot of people like. Even without now mainstream features, it's something that could be improved over time. I do believe this would be case even if a established language were introduced. The editor could be a LSP client that interact with language servers to provide the common completion and error-checking features. That could happen for GDScript, C#, or another language.

And the thing is, if we were to drop GDScript, C# is already there and working, so that would be the new main language. If the point is using a established language with a vast ecosystem, you are free to use C#.

Still, sorry I have to be the one guy that says this, but....
The change would mean that every single current plugin needs to be rewritten, more or less. This can easily trigger some people, knowing their work suddenly just got deprecated overnight. I'm quite new so I don't know if this happened with Godot 2.0 -> 3.0 transition before. I wonder if anyone who writes Godot plugins can share his or her view on the change...?

Again: API changes will be a bigger problem than GDScript syntax changes. I had a plugin to convert from 2.1 to 3.0 and wasn't that much of a deal to rewrite (I also took the opportunity to clean up code, so it was a plus).

Is &name syntax (without quotes) support planned for simple StringNames (like $Node)?

# Before:
tween.interpolate_property(self, "variable", variable, new_value, duration)

# After:
tween.interpolate_property(&variable, variable, new_value, duration)
# (The color of "&" and "variable" in the code highlight should be the same.)

# Or only:
tween.interpolate_property(&"variable", variable, new_value, duration)
# ?

@dalexeev &name would be ambiguous with the existing & operator I think

@Zylann With the bitwise AND operator? But it is binary, not unary. And code highlighting greatly affects perception. I think the choice of the & character for StringNames is due to the similarity with the syntax of pointers.

@Zylann With the bitwise AND operator? But it is binary, not unary. And code highlighting greatly affects perception. I think the choice of the & character for StringNames is due to the similarity with the syntax of pointers.

&"quoted_string_with_ampersand" can have single colour as well.

The previous syntax for super calls was to use .func_name() which can be confused as a continuation of the previous line. Now you to to explicitly use super.func_name()

will it now be possible to store superclass of A in a variable
var super_a = super
and call its method from another class (for example B)?
super_a.func(args)

something like what Python can do

class Z:
    def x(self):
        print ('Z x')

class A(Z):
    def x(self):
        print ('A x')

class B:
    a = A()
    def y(self):
        
        super(A, self.a).x()

B().y()

# prints `Z x`

Superseded by #40598.

Can yield(my_func(), "completed") be expanded upon? as in, is the only way to use await my_func() be if a 'completed' signal is raised, or has another mechanism been put in for a 'default' class signal. For example, "animation_finished"...

Can yield(my_func(), "completed") be expanded upon? as in, is the only way to use await my_func() be if a 'completed' signal is raised, or has another mechanism been put in for a 'default' class signal. For example, "animation_finished"...

The completed example is for coroutines. If you want to await for a signal you just await object.signal. It's explained in the same paragraph in the OP.

Can yield(my_func(), "completed") be expanded upon? as in, is the only way to use await my_func() be if a 'completed' signal is raised, or has another mechanism been put in for a 'default' class signal. For example, "animation_finished"...

The completed example is for coroutines. If you want to await for a signal you just await object.signal. It's explained in the same paragraph in the OP.

Yeah, my bad, I was just reading it quickly and it's late. I like that connect is becoming first-class too. If all the gdscript "string" mechanisms are wiped out completely it'll be a glorious day.